JNDI Read Write Performance issue

[Amit Doshi, módosítva 10 év-val korábban]

Hi All,

There was two site launched at Client Side:-

US Site Configuration :-
Apache Tomcat
Two liferay Cluster node with liferay 6.1 CE
Physical MSSQL SERVER.

London Site Configuration :-
Apache Tomcat
Two liferay Cluster node with liferay 6.1 CE
Virtual MSSQL SERVER.

US Site is working fine without any performance issue. We are not doing any separate read & write configuration for US Site in liferay, as all the data needs to go to the US SQL Server. We are just doing the default JNDI Settings for it.

Performance issue on London Site :-

We are doing read & write settings for london site in portal-ext.properties. On that US DB Server is used as Master Server & London DB Server is used as Slave Server.

The application does reads from London portal database and writes to the US portal database and it slow the website. It takes near about 50 Sec to 1 min to login into the site & reach at home page.

When the reads and writes are directed towards the same London database(Slave D, there is no slowness. But we can't do that because there was couple of functionality stops working & it was creating complete data mesh ups.

Last two weeks, we have used different tools WireShark, SQLSentry & Profiler but we are not able to find any clue over there. One thing we are able to found is that, some reads still occurs in US DB even if we have configured for London read. Still don't know what's the reason.

I am also attaching the screenshot of the request that takes long time. C & home takes near about 50 sec in EU Site while in US Site it takes 3 to 4 Secs.

Any help will be useful.

Thanks & Regards,
Amit Doshi

[Mika Koivisto, módosítva 10 év-val korábban]

Read-Write split is not meant to be used to create geographically split setup. Any request that writes to the database will also read from that database. What you probably need some kind of master-master database replication setup.

[Amit Doshi, módosítva 10 év-val korábban]

Thanks Mika for the quick reply.

We are using Master & Slave. We are inserting all data in the US DB and reading Data from the London DB. We were using in the past 5.2.3 the same way and it was working fine at that time. It started creating problem only after upgradation.

Any clue will be helpful.

Regards,
Amit Doshi

[Amit Doshi, módosítva 10 év-val korábban]

Mika :- For the London Site, Application server configured at London, We have Master DB at US and Slave DB at London.

It has been two weeks in our production server. Clients are complaining and couples of things goes crazy. I have to find solution for it on immediate basis. Any help will be appreciated.

Making more clear and let me know guys if anything goes wrong.

Adding portal-ext.properties :-

jdbc.default.jndi.name=jdbc/LiferayReadPool
jdbc.read.jndi.name=jdbc/LiferayReadPool
jdbc.write.jndi.name=jdbc/LiferayPool
counter.jdbc.prefix=jdbc.write.

Also add the following at the end of file:

value.object.entity.cache.enabled.com.liferay.portal.model.User=false
value.object.finder.cache.enabled.com.liferay.portal.model.User=false


spring.configs=\
  META-INF/base-spring.xml,\
  \
  META-INF/hibernate-spring.xml,\
  META-INF/infrastructure-spring.xml,\
  META-INF/management-spring.xml,\
  \
  META-INF/util-spring.xml,\
  \
  META-INF/jpa-spring.xml,\
  \
  META-INF/executor-spring.xml,\
  \
  META-INF/audit-spring.xml,\
  META-INF/cluster-spring.xml,\
  META-INF/editor-spring.xml,\
  META-INF/jcr-spring.xml,\
  META-INF/ldap-spring.xml,\
  META-INF/messaging-core-spring.xml,\
  META-INF/messaging-misc-spring.xml,\
  META-INF/mobile-device-spring.xml,\
  META-INF/notifications-spring.xml,\
  META-INF/poller-spring.xml,\
  META-INF/rules-spring.xml,\
  META-INF/scheduler-spring.xml,\
  META-INF/scripting-spring.xml,\
  META-INF/search-spring.xml,\
  META-INF/workflow-spring.xml,\
  \
  META-INF/counter-spring.xml,\
  META-INF/mail-spring.xml,\
  META-INF/portal-spring.xml,\
  META-INF/portlet-container-spring.xml,\
  META-INF/staging-spring.xml,\
  META-INF/virtual-layouts-spring.xml,\
  \
  META-INF/dynamic-data-source-spring.xml,\
  #META-INF/shard-data-source-spring.xml,\
  #META-INF/memcached-spring.xml,\
  #META-INF/monitoring-spring.xml,\
  \
  META-INF/ext-spring.xml

Context.xml

<resourcelink global="LiferayReadPool" name="jdbc/LiferayReadPool" />
<resourcelink global="LiferayPool" name="jdbc/LiferayPool" />

Server.xml

<resource name="LiferayPool" auth="Container" type="javax.sql.DataSource" driverClassName="net.sourceforge.jtds.jdbc.Driver" url="jdbc:jtds:sqlserver://xxx:1433/Portal;TDS=8.0;bufferMaxMemory=8192;bufferMinPackets=64;cacheMetaData=true;prepareSQL=3;socketKeepAlive=true;" username="sss" password="sss" maxActive="100" maxIdle="30" maxWait="3000" removeAbandoned="true" removeAbandonedTimeout="60" />
   <resource name="LiferayReadPool" auth="Container" type="javax.sql.DataSource" driverClassName="net.sourceforge.jtds.jdbc.Driver" url="jdbc:jtds:sqlserver://yyy:1433/Portal;TDS=8.0;bufferMaxMemory=8192;bufferMinPackets=64;cacheMetaData=true;prepareSQL=3;socketKeepAlive=true;" username="zzz" password="zzz" maxActive="100" maxIdle="30" maxWait="3000" removeAbandoned="true" removeAbandonedTimeout="60" />

Thanks in advance.

Regards,
Amit Doshi

[Amit Doshi, módosítva 10 év-val korábban]

Found that liferay has read & write issue in liferay 6.1. Below is the ticket for that.

https://issues.liferay.com/browse/LPS-18173

Because of the liferay issue in 6.1, anything configured to read from Slave DB, it is going for reading which was configured on the jdbc.write properties in portal-ext.properties(it will read from Master D. It is one of the major bug in liferay.

I would like one more thing on this. How it is affecting on our project.

We have 4 Custom different DB configured in liferay. But after upgrading liferay 5.2.3 to liferay 6.1, it was creating performance issue only to liferay portal, not on the custom DB. We used Wireshark tool to verify that.

I am not understanding why only liferay portal DB create major performance issue while reding from different Geographic location and it does not affect other DB.

Thanks & Regards,
Amit Doshi