[ 
https://issues.apache.org/jira/browse/IGNITE-12374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986056#comment-16986056
 ] 

swy commented on IGNITE-12374:
------------------------------

[~zstan] in my lab,

1 node with persistence=true:
------------------------------------
===================================================
NumPartial: 50
NumCompleteRec: 2000
TolRec: 100000
Duration: 62 seconds
TPS: 1613
===================================================

3 nodes with persistence=true:
------------------------------------
===================================================
NumPartial: 50
NumCompleteRec: 2000
TolRec: 100000
Duration: 173 seconds
TPS: 578
===================================================

Could you try with 3 nodes cluster as well? And any specific reason why the 
performance drop so much between 1 node cluster and 3 nodes cluster? besides 
the reason of data transfer overhead between hosts.

The application now has been simplify to all varchar columns so can run with 
578 TPS. In the first version which bigint column involved it can run only with 
~200 TPS.


> Too low performance ~200TPS for single ODBC client
> --------------------------------------------------
>
>                 Key: IGNITE-12374
>                 URL: https://issues.apache.org/jira/browse/IGNITE-12374
>             Project: Ignite
>          Issue Type: Improvement
>          Components: clients, odbc
>    Affects Versions: 2.7.5
>         Environment: Ignite server run on top of Kubernetes, with 2 server 
> nodes, persistence enabled. Both CPU and RAM at server/client server is 
> sufficient according to system reports.
>            Reporter: swy
>            Priority: Major
>         Attachments: ignite-9bb53f34.0.log, 
> ignite-logs-config-source-20191128.zip, 
> ignite-logs-config-source-20191129.zip, odbcsample, 
> odbcsample.allchar.rebind.cc, odbcsample.cc, profiling01.png, 
> profiling03.png, profling02.png, screenshot-1.png, 
> snapshot-1574845275597.nps, threaddump-1573207804944.tdump, 
> threaddump-1574845414243.tdump, values.yaml
>
>
> Hi, in our test ignite performance with ODBC connection is too bad to proceed 
> with product integration. It is about ~200 TPS, each transaction with 
> select+update operation.
> Please refer to attach sample program. It is just a simple test case. 
> Based on the profiling most of the time consumed by sql execution. Please 
> advice if the application did not do the right thing.
> Thank you.
> local ignite server, but the result same to remote container Ignite 
> deployment too.
> cat /etc/apache-ignite/my-config.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns="http://www.springframework.org/schema/beans";
>        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>        xsi:schemaLocation="http://www.springframework.org/schema/beans
>         http://www.springframework.org/schema/beans/spring-beans.xsd";>
>     <bean id="ignite.cfg" 
> class="org.apache.ignite.configuration.IgniteConfiguration">
>         <property name="clientConnectorConfiguration">
>             <bean 
> class="org.apache.ignite.configuration.ClientConnectorConfiguration"/>
>         </property>
>         <property name="binaryConfiguration">
>             <bean class="org.apache.ignite.configuration.BinaryConfiguration">
>                 <property name="compactFooter" value="false"/>
>                 <property name="idMapper">
>                     <bean 
> class="org.apache.ignite.binary.BinaryBasicIdMapper">
>                         <property name="lowerCase" value="true"/>
>                     </bean>
>                 </property>
>             </bean>
>         </property>
>     </bean>
> </beans>
> g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include 
> -I./ignite/common/os/linux/include -I./ignite/common/os/win/include 
> -I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample 
> -lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to